Guía para la implantación de la herramienta para la gestión de configuración subversión (página 2)

• Identificación de la Configuración: consiste en identificar la estructura del producto, sus componentes y el tipo de estos, y en hacerlos únicos y accesibles de alguna forma.

• Control de Cambios en la Configuración: consiste en controlar las versiones y entregas de un producto y los cambios que se producen en él a lo largo del ciclo de vida.

• Generación de Informes de Estado: consiste en informar acerca del estado de los componentes de un producto y de las solicitudes de cambio, recogiendo estadísticas acerca de la evolución del producto.

• Auditoría de la Configuración: consiste en validar la completitud de un producto y la consistencia entre sus componentes, asegurando que el producto es lo que el usuario quiere.

Sin embargo, los sistemas que automatizan la GCS suelen incluir algunas funciones adicionales, lo que lleva a ampliar la definición estándar con las siguientes actividades:

• Construcción: consiste en gestionar la compilación y enlazado de los distintos componentes del producto software de una forma lo más eficiente posible.

• Control del Trabajo en Equipo: consiste en controlar las interacciones que se producen entre los múltiples desarrolladores de un producto, sobre todo cuando deben compartir ciertos componentes del producto.

• Control de Versiones: consiste en mantener un registro histórico de las diferentes versiones por las que pasan los componentes de un producto, que permita la recuperación de cualquiera de ellas.

• Gestión de Problemas: consiste en realizar un seguimiento de la evolución de los problemas que afectan al producto.

Configuraciónn de software. Elementos de configuración de software.

Al conjunto de toda la información y productos utilizados o producidos en un proyecto como resultado del proceso de Ingeniería de Software se le denomina Configuración de Software.

A cada uno de los componentes de la Configuración del Software se le va a llamar Elemento de Configuración de Software (ECS). El ECS es la unidad de trabajo para la GCS.

El término Configuración de Software designa, por tanto, el conjunto de todos los ECS de un proyecto. Se pueden considerar como ECS los siguientes componentes:

• La especificación del sistema.

• El plan del proyecto software.

• La especificación de requisitos software.

• Un prototipo, ejecutable o en papel.

• El diseño preliminar.

• El diseño detallado.

• El código fuente.

• Programas ejecutables.

• El manual de usuario.

• El manual de operación e instalación.

• El plan de pruebas.

• Los casos de prueba ejecutados y los resultados registrados.

• Los estándares y procedimientos de ingeniería de software utilizados.

• Los informes de problemas.

• Las peticiones de mantenimiento.

• Los productos hardware y software utilizados durante el desarrollo.

• La documentación y manuales de los productos hardware y software utilizados durante el desarrollo.

• Diseños de bases de datos.

• Contenidos de bases de datos.

• Entre otros.

Para cada uno de estos elementos se almacenará al menos nombre, versión, estado y localización. En cualquier caso, para cada proyecto concreto se debe determinar qué se va a considerar como ECS.

Ahora bien, un ECS debe ser un elemento que se pueda definir y controlar de forma separada. Es decir, debe ser una unidad en sí mismo.

LINEA BASE.

Como se mencionó anteriormente, uno de los objetivos principales de la GCS es gestionar los cambios que se producen en el sistema a lo largo de su ciclo de vida.

Para controlar los cambios sin impedir los cambios justificados se utiliza el concepto de Línea Base.

Se puede definir una línea base como un punto de referencia en el proceso de desarrollo del software que queda marcado por la aprobación de uno o varios ECS, mediante una revisión técnica formal. También se puede definir como un elemento que ha sido revisado y aceptado, que va a servir como base para otros desarrollos posteriores y que solamente puede cambiarse a través de un proceso formal de control de cambios.

La idea consiste en permitir cambios rápidos e informales sobre un ECS antes de que se pase a formar parte de una línea base, pero en el momento en que se establece una línea base se debe aplicar un procedimiento formal para evaluar y verificar cada cambio.

Auditoria de la configuración.

¿Cómo se puede asegurara que el cambio se implementó correctamente? Con revisiones técnicas formales y auditorias de configuración del software.

Las revisiones técnicas se centran en la corrección técnica del ECS que ha sido modificado.  Se deben llevar a cabo para cualquier cambio que no sea trivial. Una auditoria de configuración complementa la revisión técnica al comprobar características que generalmente no tiene en cuenta la revisión, se plantea y responde las siguientes preguntas:

• ¿Se ha hecho el cambio especificado?

• ¿Se llevo una revisión técnica?

• ¿Se ha seguido el proceso del software y se han aplicado los estándares de ingeniería del software?

• ¿Se han resaltado los cambios en el ECS?

• ¿Se han seguido procedimientos de GCS para señalar el cambio, registrarlo y divulgarlo?

• ¿Se han actualizado todos los ECS relacionados?

Informe de estado.

Responde a las siguientes preguntas:

• ¿Que paso?

• ¿Quien lo hizo?

• ¿Cuando paso?

• ¿Que más se afecto?

 Los informes de estado deben realizarse para todos los cambios y cosas que se le hagan al software por cada uno de los desarrolladores, así todos están al tanto de lo que se va haciendo, de esta forma se evita el síndrome de la mando izquierda ignora lo que hizo la derecha, y un desarrollador va a cambiar lo que otro ya hizo.

Versiones, revisiones y releases

Se puede definir una Versión como una instancia de un elemento de configuración, en un momento dado del proceso de desarrollo, que es almacenada en un repositorio, y que puede ser recuperada en cualquier momento para su uso o modificación.

A las distintas versiones que aparecen en el tiempo, según se va avanzando en el desarrollo de un elemento, se les suele llamar también Revisiones.

Entre las distintas revisiones de un elemento de configuración se pueden establecer relaciones de sucesión temporal. Una representación posible para las diferentes revisiones de un elemento y sus relaciones de sucesión es mediante un Grafo de evolución o Grafo de revisión.

La manera más fácil de crear una nueva revisión de un ECS es realizar una modificación sobre la revisión más reciente. De esta manera las revisiones van formando una cadena, a la que se suele llamar Cadena de Revisión. Cada revisión en la cadena es una actualización y viene a sustituir a la revisión anterior. Normalmente se trabajará sobre la última revisión de la cadena, que es la más actual, aunque las anteriores también deben ser accesibles.

Cada una de las revisiones de un ECS se debe poder identificar de manera única, siendo común utilizar un esquema numérico, donde cada nueva versión recibe un número sucesivo.

Se suele llamar Release a una configuración del sistema que se va a comercializar o entregar al cliente.

Almacenamiento de versiones

Existen varias variantes para almacenar las versiones que se van obteniendo de un elemento de configuración. Una posibilidad es almacenar únicamente la última versión de cada uno de los ECS del sistema, pero esto puede ocasionar numerosos problemas.

A veces se tiene que versiones anteriores siguen formando parte de sistemas que están todavía en uso, por lo que hay que seguir manteniéndolas, a pesar de tener versiones nuevas más actualizadas.

Otras veces puede ser conveniente guardar versiones anteriores como punto de seguridad, al cual poder volver en caso de que un cambio efectuado no ofrezca el resultado deseado. También puede ser conveniente guardar versiones antiguas para poder reutilizar elementos que aparecían en ellas pero que fueron desechados en un momento dado.

Las herramientas de control de versiones o gestión de revisiones ayudan a crear, identificar y almacenar nuevas versiones, al mismo tiempo que se mantienen las versiones anteriores.

Sistemas de control de versiones.

Cuando se plantea la implantación de mecanismos de gestión de configuración, existen múltiples alternativas que deben ser estudiadas según las necesidades de cada caso.

La primera alternativa, aunque la más desaconsejable, es la gestión manual. En este caso, la línea base es la última versión del producto. Para modificar dicha versión es necesario formular una petición de cambio cumplimentando el formulario definido. Esta petición de cambio es evaluada por un comité para determinar la idoneidad de su implantación y, si es aceptada, se implementa generando una nueva versión. Evidentemente, para evitar que se pierda la versión anterior, es necesario almacenar una copia y es donde surgen los ficheros con nombres según la versión, fechas, ficheros comprimidos con versiones.

Esta alternativa tiene algunos aspectos bastante negativos: su gran sobrecarga, la facilidad con la que el sistema se rompe con lo que es invalidado y la lentitud que supone la burocracia en el proceso de cambio. Su único punto favorable es que es 100% adaptable a las necesidades.

Evidentemente, esta alternativa no es muy viable en la práctica. Sin embargo, existen herramientas que se encargan de automatizar prácticamente todas las tareas: los sistemas de control de versiones.

Los sistemas de control de versiones son programas que se encargan de controlar y gestionar los distintos cambios que se producen en el producto. Este producto puede ser desde el código de un programa, hasta documentos de texto, diagramas, imágenes, planos, etcétera.

Todos los sistemas de control de versiones se basan en el concepto repositorio. Un repositorio no es más que el conjunto de versiones del producto. Una vez creado, los distintos usuarios realizan sus cambios sobre el repositorio que se encarga de almacenarlos permitiendo la recuperación de cualquier versión. Existen dos tipos de repositorios:

Centralizado:

El repositorio es único y reside en una máquina accesible por cualquier usuario. Este es el modelo más usual.

Distribuido:

En este caso, existen múltiples repositorios accesibles por cada usuario. Cada usuario utiliza un repositorio cualquiera y existen mecanismos de sincronización entre repositorios.

En cualquiera de los dos casos, el repositorio es compartido por todos los usuarios (o al mismo usuario desde distintas máquinas) que tengan acceso al mismo. Es posible que se produzcan ediciones simultáneas de los mismos elementos que generen conflictos. Para solucionar este problema existen dos políticas básicas de resolución de conflictos:

bloqueo-modificación-desbloqueo:

En esta política se evitan las modificaciones concurrentes. Cuando un usuario desea realizar una modificación, indica el elemento a modificar que queda bloqueado en el repositorio por lo que se impide el acceso al resto de usuarios (exclusión mutua). Cuando finaliza de realizar sus cambios, los envía al repositorio liberando el bloqueo con lo que el resto de los usuarios puede obtener la copia actualizada para realizar sus propios cambios.

copiar-modificar-mezclar:

Esta política permite las modificaciones simultáneas. Cada usuario hace una copia del repositorio en su máquina y procede trabajar con ella como si no fuera un repositorio. Cuando finaliza su trabajo, envía los cambios al repositorio que se encarga de analizar los cambios realizados por el usuario y los que se han realizado en el propio repositorio y realiza la mezcla.

Evidentemente, la primera política es mucho más restrictiva lo que dificulta el trabajo diario ralentizando el acceso a los recursos y ocasionando problemas si no se liberan recursos bloqueados. La segunda, por su parte, tiene como inconveniente que no siempre es posible mezclar los cambios realizados aunque en esos casos, utiliza al usuario que envía cambios para solucionar esos conflictos irresolubles automáticamente.

Existen numerosas aplicaciones para controlar versiones: CVS, Sourcesafe, Subversion, entre otras, cada una con sus características únicas. En el próximo epígrafe se abordará una de las más populares "Subversion".

Sistemas de control de versiones: Subversion.

De los múltiples sistemas existentes, uno de los más útiles y utilizados es Subversion (SVN) . SVN surge para reemplazar al gestor usado en sistemas Unix (CVS) con el objetivo de mejorar algunos aspectos que dificultaban el uso de la aplicación. Existen versiones tanto del cliente como del servidor para cualquier plataforma.

El servidor de Subversión gestiona un repositorio centralizado con la política copiar-modificar-mezclar. Sin embargo, existen herramientas para sincronizarlo con otros repositorios y es posible configurar repositorios con la política bloquear-modificar-desbloquear. Las características fundamentales son:

• Número de versión global al repositorio que se incrementa con cada cambio, por lo que es posible volver a una versión anterior indicando dicho número global.

• Control de cambios en ficheros y directorios (si, almacena y controla cambios en árboles completos de carpetas y ficheros). Mantiene el histórico de versiones de un fichero aunque se mueva o renombre.

• Detecta y trata apropiadamente los ficheros binarios, uno de los puntos débiles de CVS. A estos ficheros les añade una propiedad indicando su tipo.

• La transmisión entre cliente y servidor incluye únicamente los cambios lo que supone un ahorro del ancho de banda. Además, los cambios se calculan a nivel de byte (en lugar de línea ampliamente usado) lo que reduce aún más el tamaño de las modificaciones.

Por su parte, es posible acceder al servidor utilizando distintos clientes independientemente de la plataforma en la que ejecute cada uno de ellos. Es posible utilizar un cliente en Windows que se conecte con un servidor en Unix o Mac y viceversa. Esta facilidad, permite la creación de clientes bastante avanzados adaptados a cada plataforma como, por ejemplo, la integración con documentos de office que dispone el cliente de Windows.

El uso de subversión es muy sencillo. El proceso si se usa una consola es:

svn co ruta_repositorio [destino]

Descarga una copia (checkout) de cualquier carpeta contenida en el repositorio (no es necesario bajar la raíz del repositorio, se puede bajar cualquier carpeta contenida en el mismo) que se denominará copia de trabajo. La copia de trabajo son ficheros locales en la máquina por lo que puede ser modificada según se desee.

Las rutas de repositorio tienen la forma protocolo://usuario:password@servidor/ruta. Existen múltiples protocolos como Webdav, svn (protocolo propio), svn+ssh (protocolo svn a través de un túnel ssh para asegurarlo…

svn update

Se encarga de descargar los últimos cambios del repositorio y mezclarlos en la copia de trabajo para que coincida con la última versión disponible.

Si en el proceso de mezcla se detectan conflictos irresolubles, se marcan en la copia de trabajo para que el usuario los resuelva. De esta forma, se evita corromper el repositorio.

svn ci [ruta]

Cuando se finalizan los cambios se envían al repositorio (commit). En este momento, se comprueba si la versión base del usuario es la última del repositorio y si es así se envían los cambios creando una nueva revisión.

Si las versiones no coinciden, el usuario deberá actualizar (update) su copia de trabajo con lo que se marcarán los conflictos en la copia de trabajo.

Además de este cliente de consola, existen aplicaciones gráficas que realizan ese trabajo de forma transparente y más agradable para el usuario.

Si se utiliza Windows, la opción más adecuada es TortoiseSVN.
Es un cliente que se integra con el explorador de Windows y que permite realizar
todas las acciones mediante entradas en el menú contextual de los ficheros
y carpetas.

Para el escritorio KDE existe un plugin similar denominado kdesvn
aunque no implementa toda su funcionalidad. Sin embargo, para un uso habitual
es suficientemente útil.

Repositorios en Subversion.

Como ya se planteó anteriormente, SVN es un sistema de control de versiones con la política copiar-modificar-mezclar con gran proyección en la actualidad. Por ejemplo, SourceForge (una forja de proyectos libres) utiliza SVN como control de versiones. Gran parte del éxito de SVN se debe a su agilidad cuando intervienen varias personas, debido a su política, y a su flexibilidad que no lo limita a desarrollos de software: es posible almacenar planos, imágenes, libros, etcétera.

Pero esta flexibilidad puede volverse en contra del usuario: al crear el repositorio en su interior no existe absolutamente nada y nos encontramos ante el "síndrome de la hoja en blanco". Para poder extraer el máximo partido a la herramienta es necesario definir una estructura de directorios en la que se almacene la información. Y hay algunas mejores que otras.

Aunque no es obligatorio, prácticamente todos los proyectos de SVN tienen un primer nivel común. Las políticas aplicadas en este nivel proporcionan coherencia en la gestión y funcionalidades no disponibles de forma nativa. Esta estructura se compone de tres directorios (branches, tags y trunk) y una cuarta opcional (vendor). Es necesario definir cómo funcionan y se usan cada uno de ellos, cómo se gestionan múltiples proyectos, entre otras cosas.

Estructura o layout del repositorio.

Ya se ha creado el repositorio por lo que se tiene la "hoja en blanco" en revisión 0. Es el momento de hacer el primer commit que dará lugar a la revisión 1, la más importante de todas ya que definirá el funcionamiento futuro del repositorio. Esta revisión crea la estructura raíz del repositorio y el funcionamiento global del mismo.

Tras multitud de experiencias, lo más recomendable para este primer commit es crear tres directorios o carpetas: branches, tags y trunk. Si está previsto utilizar algo desarrollado por terceras personas se debería crear un cuarto directorio: vendor.

El tronco o rama principal: trunk

Este directorio contiene la versión actual de trabajo sobre la que se realizan las modificaciones, es decir, el código/documentos/imágenes sobre las que se está trabajando en este momento.

Es la zona de trabajo habitual en la que los desarrolladores realizan sus modificaciones.

Como política adicional esta rama siempre tiene que tener algo correcto: si es un programa debe compilar, si es un documento en LaTeX debe poder convertirse. En los últimos tiempos se utilizan técnicas de integración continua para asegurar el cumplimiento de esta política.

Las hojas más importantes: tags

Cuando en la rama principal (trunk) se tiene una versión que se va a entregar al cliente habitualmente es necesario registrar cuál es para poder volver a ella en caso de problemas. SVN no proporciona un mecanismo integrado para realizar esta tarea por lo que se surgen dos opciones:

• Tener un fichero que almacene la versión del repositorio que debe gestionarse. Esta opción es poco recomendable.

• "Copiar" la versión actual del trunk en la carpeta tags (svn cp repositorio/trunk repositorio/v.vv.vv).

La segunda opción es la más recomendable ya que suprime las necesidades de gestión al máximo. Además, hay que destacar que la copia no es tal ya que, al no existir modificación en el fichero, SVN no copia los datos sino punteros para utilizar los mismos ficheros.

Aunque es posible realizar modificaciones sobre tags, se recomienda mantenerlas inmutables.

El laboratorio: branches

Cuando se quiere hacer algún tipo de prueba, trabajo que pueda corromper la rama principal o gestionar cambios en una versión vieja que está en mantenimiento se puede trabajar fuera del repositorio (poco recomendable y, dependiendo de la envergadura del trabajo, puede ser muy difícil volver a integrarlo en la principal) o utilizar una rama. El proceso habitual es copiar el trunk a una subcarpeta de branches, realizar los experimentos (subiendo las versiones necesarias) y, si son exitosos, mezclar los cambios con el trunk para seguir el desarrollo.

Estas ramas pueden crearse o destruirse según las necesidades y mezclar cambios con cualquier otra rama sin demasiados problemas. Además, la política de mantener la rama incorrupta no se aplica en las ramas lo que proporciona mayor libertad y permite usar una rama para almacenar una serie de pasos que dejarían corrupta la rama principal.

Aprovechando el conocimiento universal: vendor

Es habitual utilizar trabajo realizado por terceras personas (bibliotecas en un lenguaje de programación, un trabajo de universidad de otro compañero…) que es necesario controlar. Para integrarlas en SVN se utilizan las ramas de proveedor.

La política de estas ramas permite almacenar el conjunto de versiones de las bibliotecas e integrarlas de forma transparente en el código propio. Además, permiten realizar modificaciones personales sobre la biblioteca e integrarlas con las futuras versiones de la misma.

La gestión se compone de los siguientes pasos:

• Importar la versión actual:svn import ruta/biblioteca repositorio/vendor/biblioteca/current –m: importar biblioteca vX.YY.

• Etiquetar la versión:svn copy repositorio/vendor/biblioteca/current repositorio/vendor/biblioteca/X.YY –m: Etiquetar biblioteca vX.YY.

• Integrarla en la rama principal:svn copy repositorio/vendor/biblioteca/X.YY repositorio/trunk/libs/ -m: Añadir biblioteca vX.YY a la rama principal.

Cuando se quiere integrar una nueva versión de la biblioteca, se modifica la versión current, se etiqueta y se utiliza svn merge para añadir los cambios.

Un caso especial son las bibliotecas ya gestionadas en un repositorio
SVN al que se tiene acceso. En este caso, si no se va a realizar ninguna modificación
en el código o si se dispone de la posibilidad de modificar el repositorio
externo, es posible enlazar directamente el repositorio de la biblioteca utilizando
utilizando repositorios externos. En este caso, basta con definir la propiedad
svn:external como biblioteca repositorio para que SVN descargue el código
externo de forma transparente.

Un repositorio por proyecto o múltiples proyectos en un repositorio.

Esta es la duda eterna en el uso de SVN. Existen argumentos a favor y en contra de cada una de las dos que, puestos en una balanza, no arrojan un claro vencedor. Para no alargar en exceso se expone opción que, de forma absolutamente personal, parece más útil: múltiples repositorios.

La idea es que cada proyecto tenga su propio repositorio con la estructura estándar en su raíz. De esta forma toda la información relacionada con el proyecto está controlada y gestionada con las mismas políticas, simplifica la migración y tiene un número de revisión único.

El principal punto en contra son las piezas comunes entre proyectos: ¿quién gestiona una biblioteca común a dos o más proyectos? La respuesta es sencilla: si es compartido pasa a disponer de su propio repositorio. Antes de que las manos lleguen a la cabeza y se inicien los gritos y la quema:

• Si lo utilizan varios proyectos es más que probable que tenga entidad suficiente para ser un proyecto per se.

• Se puede añadir utilizando referencias externas, por lo que el funcionamiento es completamente transparente en cualquier proyecto. Además, se simplifica su inclusión en cualquier otro futuro proyecto que lo precise.

• Se puede definir políticas especiales adaptadas a la biblioteca, establecer un sistema de validación automática.

• Agrupando las zonas comunes (más o menos relacionadas) de varios proyectos se creará la biblioteca reutilizable para toda la organización sin grandes esfuerzos. Esta biblioteca crecerá según las necesidades y con el esfuerzo de de todos.

Hasta aquí se han visto las características de SVN, la estructura general de los repositorios que se recomienda utilizar, así como la posibilidad de definir un repositorio por proyectos o varios proyectos en un repositorio. Ahora bien ¿cómo instalar y configurar SVN para automatizar la gestión de la configuración?

La respuesta a esta interrogante se describe en el siguiente epígrafe

Instalación de subversión en Windows. Integración con Apache

Seguidamente se describen los pasos necesarios para la instalación de Subversión (SVN), su integración con el servidor web Apache, así como se muestran ejemplos del uso de esta herramienta.

Instalación de subversion.

Descargar e instalar el fichero svn-1.4.6-setup.exe (versión de los binarios de SVN para Apache 2.2 en Windows) desde:

http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=8100&expandFolder=8100&folderID=8100 En los sucesivo para hacer referencia a la dirección donde se instaló Subversión se hará mediante SVN_INSTALL_DIR, por ejemplo, si se realizó una instalación estandar de SVN sobre el sistema operativo Windows XP en inglés, entonces SVN_INSTALL_DIR hace referencia a la dirección "C:/Prorgam Files/Subversion".

Instalación del servidor web Apache.

Descargar e instalar una versión actualizada de Apache (en este documento se hace referencia a la versión 2.2.9) a través de http://httpd.apache.org/download.cgi . En este caso, la distribución utilizada es "Win32 Binary without crypto (apache_2.2.9-win32-x86-no_ssl-r2.msi)".

En los sucesivo para hacer referencia a la dirección donde se instaló Apache se hará mediante APACHE_INSTALL_DIR, por ejemplo, si se realizó una instalación estandar de Apache sobre el sistema operativo Windows XP en inglés, entonces APACHE _INSTALL_DIR hace referencia a la dirección "C:/Prorgam Files/Apache Software Foundation/Apache2.2".

INTREGRACIÓN DE SVN CON APACHE.

En los siguientes epígrafes se describen las operaciones necesarias para la integración de SVN con Apache.

Copiar los ficheros necesarios para la integración.

Una vez realizado el paso anterior, hay que copiar todos los ficheros .dll del directorio  "SVN_INSTALL_PAHT/bin" junto con los archivos mod_dav_svn.so y mod_authz_svn.so, al directorio "APACHE_INSTALL_DIR /modules". Además, para que no haya problemas, también habrá que copiar los ficheros .dll del directorio "APACHE_INSTALL_DIR /bin" al directorio "APACHE_INSTALL_DIR /modules". (solo deben copiarse los .dll que no estaban ya en el directorio "APACHE_INSTALL_DIR/modules"). Con esto se logra copiar las librerías del SVN necesarias para que Apache pueda cargar los módulos del SVN al arrancar.

Para hacer más sencillo los pasos posteriores, se incluirán en la variable de entorno PATH la ruta del SVN y de Apache. Para ello hacer clic derecho sobre My Computer->Properties->Advanced->Environment Variables y editar la variable PATH (nótese que si el lenguaje del sistema operativo es el español sería Mi PC->Propiedades->Opciones de Avanzada->Variables de Entorno). Veanse Figura 1 y Figura 2.

Figura 1. Selección de la variable de entorno PATH.

Figura 2. Modificacion de la variable de entorno PAHT.

En esa variable hay que adicionar al final el directorio bin del SVN ("SVN_INSTALL_PATHbin") y la ruta del directorio bin de Apache ("APACHE_INSTALL_PATHbin").

Configuraciones para que Apache cargue los módulos de SVN.

Para que Apache carge los módulos de SVN cada vez que arranque (los módulos copiados en el epígrafe 2.1) es necesario modificar el fichero "APACHE_INSTALL_DIR /conf/httpd.conf" adicionando las siguientes líneas (en la sección donde se cargan los módulos):

LoadModule dav_svn_module modules/mod_dav_svn.so

LoadModule authz_svn_module modules/mod_authz_svn.so

LoadModule dav_module modules/mod_dav.so (es probable que exista, simplemente hay que asegurarse de que no esté comentada).

LoadModule dav_fs_module modules/mod_dav_fs.so (es probable que exista, simplemente hay que asegurarse de que no está comentada).

Definición de parametros para el acceso a los repositorios SVN vía http.

Para definir los parámetros para el acceso a los repositorios del SVN via http, primeramente se creará el fichero httpd-subversion.conf dentro del directorio "APACHE_INSTALL_DIR /conf/extra" y posteriormente adicionar las siguientes líneas en dicho fichero:

svn>

DAV svnSVNParetPath "D:/Temp/RepoSVN"

SVNListParentPath off

AuthType BasicAuthName "Subversion repository"Require valid-userAuthUserFile "APACHE_INSTALL_DIR/conf/access-policy/svn-users.conf"

AuthzSVNAccessFile "APACHE_INSTALL_DIR/conf/access-policy/svn-groups.conf"

IMPORTANTE: Los datos que aparecen en negrita dependerán de la máquina donde se esté realizando la instalación y de las necesidades de cada caso. Seguidamente se describen cada uno de los elementos:>: define la url para acceder por http "http://:/svn" (por ejemplo http://maquina:80/svn).

SVNParentPath "D:/Temp/RepoSVN": define que cuando se acceda a la url http://:/svn realmente se estará accediendo al directorio físico que indica esa ruta ("D:/Temp/RepoSVN" es el directorio raiz de todos los repositorios para los ejemplos que se mostrarán es este documento, por tanto, debe sustituirse esta dirección por la que se defina para este fin). Como se necesita crear constantemente nuevos repositorios (uno por cada proyecto), se definie el directorio RepoSVN como "padre" de todos ellos, es decir, todos los repositorios que se vayan creando serán subdirectorios de RepoSVN aunque en sí mismo "NO" sea un repositorio.SVNListParentPath off: por lo descrito en el punto anterior, el directorio RepoSVN es solo el padre de todos los repositorios, pero en sí mismo no es uno de ellos, de ahí que esté marcado como off.SVNPathAuthz on, AuthType Basic y AuthName: se refieren a que está activada la autenticación de usuarios (se muestra la típica pantalla para introducir usuario / contraseña), el tipo de autenticación que se lleva a cabo y el nombre que sale en la ventana de autenticación, en ese orden.AuthUserFile "APACHE_INSTALL_DIR /conf/access-policy/svn-users.conf": indica el fichero donde se van a tener los usuarios (con sus contraseñas encriptadas) que pueden hacer uso de SVN (posteriormente se detalla cómo modificar dicho fichero).

Require valid-user: indica que la validación de usuario es obligatoria.

AuthzSVNAccessFile "APACHE_INSTALL_DIR /conf/access-policy/svn-groups.conf": una cosa son los usuarios que tienen acceso a utilizar SVN (especificados en "APACHE_INSTALL_DIR /conf/access-policy/svn-users.conf") y otra es la definición de a que repositorios tienen acceso esos usuarios. Esto es precisamente lo que se establece en el fichero "APACHE_INSTALL_DIR /conf/access-policy/svn-groups.conf" (posteriormente se indica cómo hacerlo).

Luego de haber definido los parametro necesarios para acceder a los repositorios SVN vía http en el fichero httpd-subversion.conf, es necesario adicionar la siguiente línea al final del archivo "APACHE_INSTALL_DIR/conf/httpd.conf" para incluir estos parámetros en la configuración de Apache:

Include "APACHE_INSTALL_DIR/conf/extra/httpd-subversion.conf"

El próximo paso es crear los ficheros "APACHE_INSTALL_DIR/conf/access-policy/svn-users.conf" y "APACHE_INSTALL_DIR /conf/access-policy/svn-groups.conf" definidos anteriormente.

Hasta aquí se realizaron las operaciones necesarias para la integración de SVN con Apache, en los próximos epigrafes se mostrarán ejemplos de la utilización de lo descrito hasta este momento.

Usuarios, repositorios y acceso de los usuarios a los repositorios.

En los epígrafes susecivos se descibe como agregar usuarios, repositorios y como controlar el acceso a estos últimos en SVN con Apache.

Agregar usuarios al fichero svn-users.conf.

Para agregar un nuevo usuario al fichero que se definió anteriormente "APACHE_INSTALL_DIR /conf/access-policy/svn-users.conf" es necesario utilizar la herramienta htpasswd del Apache.

Para facilitar el trabajo se puede copiar dicha herramienta que se encuentra en el directorio "APACHE_INSTALL_DIR /bin" al directorio "APACHE_INSTALL_DIR /conf/access-policy". Una vez realizado esto se debe abrir una ventana de comandos de Windows, ubicarse en "APACHE_INSTALL_DIR /conf/access-policy" y escribir la siguiente línea:

htpasswd svn-users.conf

Por ejemplo:

htpasswd svn-users.conf admin

Con eso, el sistema pedirá la contraseña y la confirmación de la misma para terminar de adicionar el usuario (ver Figura 3).

Figura 3. Creación de usuario con la herramienta hhtpasswd.

Una vez terminado el proceso si se mira el contenido del fichero "APACHE_INSTALL_DIR /conf/access-policy/svn-users.conf" puede verse algo del tipo:

admin:$apr1$g55…..$bKJ1DGe54OIj2kJQLU3Gl0

La secuencia alfanumérica que puede verse no es más que la contraseña introducida para el usuario admin encriptada con md5.

Crear un nuevo repositorio.

Para crear un nuevo repositorio es necesario abrir una ventana de comandos de Window ubicarse en "D:/Temp/RepoSVN" (se debe recordar que se debe sustituir esta dirección por la dirección raiz de los repositorios) y escribir la siguiente línea:

svnadmin create (este comando crea un repositorio con nombre repo-name y una serie de subdirectorios con la estructura necesaria del repositorio: conf, dav, db, hooks, locks y el fichero format)

Ejemplo:

svnadmin create sample-repo (se creará un repositorio con nombre sample-repo) (ver Figura 4).

Con estos pasos habrá quedado creado el nuevo repositorio con nombre simple-repo.

Figura 4. Creación de un nuevo repositorio.

Acceso de usuarios a los repositorios.

Tal y como se comentaba en el epígrafe 3.2, el hecho de que un usuario esté añadido al fichero "APACHE_INSTALL_DIR /conf/access-policy/svn-users.conf" no significa que puede acceder libremente a todos los repositorios. Para ello existe el fichero "APACHE_INSTALL_DIR /conf/access-policy/svn-groups.conf" que precisamente cumple la función de definir que usuarios tienen accesos a los repositorios.

Si por ejemplo hubiese dos usuarios dados de alta en SVN (admin y user con sus correspondientes entradas en el fichero svn-users.conf) un ejemplo del contenido del fichero svn-groups.conf podría ser:

[/]*=r

[simple-repo:/]guest=radmin=rwuser=rw

Con esto se indica que los dos usuarios pueden leer y escribir en el repositorio sample-repo.

Como se puede apreciar, esta forma de difinicion de acceso a los repositorios se basa en definir para cada uno de los usuarios, los repositorios a los que puede acceder. Existe otra forma de definir el acceso a los repositorios y es mediante la asociación de los usuarios a grupos de usuarios, de esta forma, en vez de definir el acceso para cada uno de los usuarios, se definirían los accesos para cada grupo. Por ejemplo:

[/]*=r

[groups]

repo-admins = admin,user,peter

[sample-repo:/]

@repo-admins = rw

Con esto se indica que los dos usuarios que pertenecen al grupo repo-admins (admin, user , peter) pueden leer y escribir en el repositorio sample-repo.

Si se quisiera probar el correcto funcionamiento del nuevo repositorio creado en el epígrafe 3.2, se puede acceder con un explorador a http://:80/svn/sample-repo. Se debería mostrar la pantalla de autenticación del usuario, una vez introducido el usuario y contraseña se mostraría una página indicando la versión del SVN.

Clientes de SVN.

Hasta este momento se han indicado los pasos a seguir para instalar e integrar SVN con Apache, pero ¿cómo se interactúa con el repositorio desde un cliente?. Existen varios clientes de SVN que funcionan bastante bien, pero en este caso se explicará el uso con el Tortoise. Para ello se puede descargar e instalar desde http://tortoisesvn.net/downloads.

Una vez instalado, se puede ver como al pulsar el botón derecho del ratón salen nuevas opciones (ver Figura 5).

Figura 5. Nuevas opciones en el menú contextual al instalar Tortoise.

Obtener el contenido de un repositorio.

Para obtener el contenido de un repositorio, lo único que se tiene que hacer es crear un directorio, pulsar el botón derecho de ratón y seleccionar SVN Checkout…. Se solicitará la ruta del repositorio del que se quiere obtener el contenido (realizar el checkout) y el directorio de destino (ver Figura 6 y Figura 7).

Figura 6. Obtener el contenido de un repositorio mediante Tortoise.

Figura 7. Ventana para introducir los datos del SVN Checkout…

Importar datos a un repositorio.

Si lo que se quiere hacer es introducir una serie de ficheros a un repositorio recien creado, habrá que acceder al directorio donde se encuentran esos nuevos ficheros, pulsar el botón derecho del ratón y seleccionar TortoiseSVN->Import… tal y como se muestra en la Figura 8.

Figura 8. Importar datos a un repositorio.

Saldrá una ventana donde se debe introdicir la dirección del repositorio, al hacer clic en el botón OK y realizará el import (Ver Figura 9).

Figura 9. Ventana para introducir los datos del import de SVN.

Update y Commit en el repositorio.

Una vez que realizado un checkout de un repositorio, se podrá ver como los ficheros y directorios quedan marcados con unos iconos característicos que ayudan a saber la sincronía con los ficheros del repositorio. En caso de que se haya modificado algo aparecerá un icono en rojo. Para subir los cambios realizados al repositorio es necesario hacer un commit de los cambios reliados, para ello habrá que pulsar el botón derecho del ratón y seleccionar SVN Commit… (ver Figura 10).

Figura 10. SVN Commit mediante Tortoise.

Si por el contrario queremos actualizar nuestros ficheros locales con el contenido del repositorio, habrá que seleccionar la opción SVN Update.

Conclusiones

En este decumento se describió una guía para la instalación de la herramienta SVN sobre Windows XP así como las integración de esta con el servidor web Apache. Dicha guía puede ser usada por cualquier empresa o institución que desee implantar un sistema para la Gestión de Configuración apoyado el la herramienta SVN.

Bibliografía

Barrientos, Leo. 2007. Estructura de SVN para proyectos de Software. [Artículo de Sitio web de Internet] 5 de noviembre de 2007. [Última visita: 12 de noviembre de 2008]. Disponible en:

http://leobarrientosc.blogspot.com/2007/11/estructura-de-svn-para-proyectos-de.html

Febles, Ailyn. La gestión de configuración y el desarrollo de software en las universidades. Una experiencia práctica. Revista cubana de educación superior. 2005. Vol. 25. Nº 1. pags. 69-80. Disponible en: http://dialnet.unirioja.es/servlet/articulo?codigo=2435578

Grey Literature International Steering Committee. Directrices para la producción de informes

científicos y técnicos: como escribir y distribuir literatura gris. Versión 1.1. GLISC, 2007.

International Organization for Standardization. Documentation – Presentation of scientific and technical reports. Geneva: ISO, 1982. (ISO 5966).

Jacobson, Ivar, Booch, Grady, Rumbauh, James. El Proceso Unificado de Desarrollo de Software .2000. Addison Wesley.

Pressman, Roger S. 2002. Ingeniería de Software. Un enfoque próctico. s.l. : McGraw.Hill/Interamericana de España, 2002. 5.

Webamedia. 2008. Instalación Apache y Subversion en Windows. [Artículo de Sitio web de Internet] 7 de marzo de 2008. [Última visita: 20 de noviembre de 2008]. Disponible en:

http://webamedida.net/index.php?option=com_content&task=view&id=16&Itemid=15

WordPress. 2008. Gestión de Configuración. [Artículo de Sitio web de Internet] 17 de marzo de 2008. [Última visita: 26 de noviembre de 2008]. Disponoble en:

http://ocubom.wordpress.com/2008/03/17/gestion-de-configuracion/

Autor:

Diosmani Meri?o Hechavarr?a

Santa Clara, Cuba

24 de enero de 2010

EMPRESA NACIONAL DE SOFTWARE DESOFT "VILLA CLARA"